Technical systems, such as power plants, energy distribution networks, manufacturing equipment in industry, transportation facilities, electric vehicle charging networks, or the like have a number of constraints. To name only a few, the systems need to be highly available, the systems can be complex with a number of inter-related components, and some of the systems operate in an automatic or semi-automatic operation mode.
To address these and other constraints, technical components capable of influencing technical process execution can be provided with redundancy, and the technical systems can be connected to control systems. The control systems include computers at substantially all levels. Computers can assist to control the technical system as a whole, for example, computers in control centers, control systems, or automation systems. Computers can be associated with individual components that implement an industrial process or with elements of the components.
In an industrial environment, the computers can be implemented as controllers with a central processing unit (CPU), communication module, and power supply module. An example for a controller is the controller that is commercially available from ABB Automation GmbH, Mannheim, Germany under the trademark “AC 800M”.
Using redundancy for the computers and for controllers is common. Popular redundancy approaches include warm standby (or hot standby) and N-modular redundancy. Usually, the redundancy schemes can be selected according to the desired overall availability of the system.
Much simplified, with hot or warm standby, a stand-by controller substantially provides identical function as the controller in operation or active controller, and if the controller in operation fails, the standby controllers take over (one-to-one). Until the controller in operation is being replaced, the system is no longer tolerant to faults.
Controllers in an N-modular arrangement can be substantially operative all the time according to substantially identical programs. Their output is compared in a voting scheme with implicit error detection so that the output of a malfunctioning controller is disregarded. An example for an N-modular arrangement is the arrangement 2-out-of-3 (2oo3, or “Triple Modular Redundancy”).
However, any redundancy calls for technical resources, such as the provision and operation of additional controllers. This leads to additional power consumption and maintenance efforts, computing overhead (for the voting scheme) and the like. The demand for technical resources increases with the desired overall availability. This conflict should be addressed.
In a control system and a controller system respectively with three or more controllers, the controllers can be associated with technical entities. The controllers execute tasks individually and separately, but some controllers share task instructions as peers. With respect to an exemplary first task, the instructions can be distributed to a first controller that executes the first task in interaction with the associated technical entities, in the so-called primary mode. The instructions can be distributed to a second controller that provides redundancy for the first task. Thereby, the second controller does not interact with the associated technical entities, in the so-called secondary mode. Regarding an exemplary second task, the instructions can be distributed to a third controller that executes the second task—in the primary mode—and to the first controller that provides redundancy for the second task.
In other words, the first controller can have the second controller as a task execution peer, and the first controller is the redundancy peer to the third controller. If one of the controllers becomes non-available, the peer-to-peer relation changes.
For example, if the first controller becomes non-available, the second controller takes over the first task. To regain redundancy for the third task, the second controller becomes the redundancy controller for the third task.
Non-availability can occur at several degrees of severity: Non-availability can include total non-availability in that a controller cannot execute any task at all. Non-availability can also include partial non-availability in that the controller can execute at least some tasks, or can execute the tasks with reduced speed or bandwidth.
Exemplary embodiments of the present disclosure allow the distribution of non-availability risks over multiple controllers. To save resources, the tasks are not executed by two or more controllers in parallel (as in an N-redundancy scheme or in hot standby). The approach takes advantage of the technical features of modern controllers, such as sufficient capacity (memory and processor) to execute multiple tasks at the same time.
A controller spends electrical energy corresponding to the number of tasks, so that a controller for two or more tasks temporarily can have increased energy spending as compared to a single-task controller, but energy spending will balance out as soon a replacement controller starts operation.
Modern controllers usually have sufficient capacity to execute multiple tasks, or to temporality execute additional tasks. The controllers may be equipped with additional hardware (for example, memory), but extra costs can be negligible so that costs could be saved in comparison to having a dedicated controller to act as secondary controller. In other words, free capacity of controllers is used when the controller executes tasks as a secondary controller, provided that the task execution as a secondary controller does not interfere with the normal task execution as primary controller. In contrast to deployments known in the art, additional controllers for redundancy provisioning are not specified.
Non-availability of a controller can have a variety of reasons, such as a failure or defect in the controller hardware (memory, processor, bus, storage etc.) or even in the controller software.
In principle, the approach is not sensitive to non-availability. The approach can also be applied for maintenance of the controllers. Maintenance can be hardware maintenance or software maintenance. The service person who is in charge to maintain the controllers, can simply switch off a controller, and a different controller takes over operation. The maintenance of a single controller does not interrupt the operation of the controller system as a whole, non-interrupted maintenance can be achieved. A number of different tasks can be distributed for execution across several controllers in the primary and secondary modes for the tasks. A controller becoming inactive (e.g., non-available) triggers the controllers in the secondary mode to take over the execution of tasks in the primary mode. This operation can be useful for implementations with multiple rail-mounted controllers, in that controllers can be replaced.
The execution of the task can be moved back to the original controller (that executed the task first) when it is available again or if a replacement controller has been installed. Moving back can be accomplished with synchronization.
Controllers that execute tasks assume certain states with respect to data being processed, variables or registers being set. State information can be preserved and communicated between the controllers, for example, as checkpoints or data signals.